sdk: give v1 byte fields the type the proto declares - #1124

Three defects an adversarial pass found in the conversion itself.

Rust's `report_data` kept `#[builder(into)]`, and both `&str` and
`String` implement `Into<Vec<u8>>`. So `.report_data("00ff")` still
compiled and attested the four ASCII bytes of that string -- exactly the
failure the change was made to eliminate, on the one field a caller
sends rather than receives. It is now a `ReportData` newtype that
converts from a `Vec<u8>`, an array or a slice and from nothing else, so
the builder keeps the coercion that made those three ergonomic while a
string becomes a type error. A `compile_fail` doctest keeps it one.

JavaScript decoded with `Buffer.from(value, 'hex')`, which stops at the
first pair it cannot parse and returns the prefix, silently: a corrupted
`app_id` came back as a short `Uint8Array`, `signature_chain:
["aabb","qq"]` came back one link short, and an absent required field
came back as an empty array that is *truthy*, so `if (!info.app_id)`
guards became dead code. Rust, Python and Go all reject these. It now
throws and names the field, and absence of a required field is an error
rather than empty bytes -- `os_image_hash` and `mr_aggregated` still
read as empty, so a degraded `Info` stays parseable.

Python accepted hex with embedded whitespace, which `bytes.fromhex`
skips, while raising a message that said it did not; and it rejected a
response that omits `os_image_hash` or `mr_aggregated`, where Rust has
`#[serde(default)]`. Both aligned.

None of this was covered: JS and Python had zero negative tests for any
v1 byte field, which is why a green suite proved nothing here. Added,
and mutation-checked -- four of the five new JS tests fail against the
old lenient decoder.

Also corrects the CHANGELOG, which said four of the eleven fields had no
Rust decoder where the number is three, and which claimed "the wire is
unchanged" without saying that only the JSON wire is: borsh writes a
`Vec<u8>` as length-prefixed bytes where it wrote a hex `String`, so a
0.5.x blob deserializes without error into the wrong content. Three
comments called `os_image_hash` and `mr_aggregated` `optional` on the
wire; the proto declares them plain `bytes`, and `not_before` and
`not_after` are the only `optional` fields it has. Tolerating their
absence is a client-side choice, and now says so.

Rust and Go always took bytes here. Python and JavaScript also accepted a
string and UTF-8 encoded it, which reads as a convenience right up until
the string is a hex digest:

    client.attest("deadbeef")   # eight ASCII characters, not four bytes

No error, no exception, just a quote over a value the caller did not
mean. `attest_gpu` was worse: SPDM fixes the nonce at 32 bytes, so a
32-character string passed the length check on its way to attesting the
wrong nonce, and the check that was supposed to catch a bad nonce was
the reason this one got through.

This is the request-direction half of typing the v1 `bytes` fields. The
response half made a hex string unspellable where bytes were meant; the
same argument applies to the two fields a caller sends, and Rust's
`AttestConfig` already got it in the form of the `ReportData` newtype.
Both SDKs now raise, and name the two ways out -- encode the text or
decode the hex -- because only the caller knows which was meant.

Python routes both parameters through one `_require_bytes`, so the two
methods cannot drift: `attest_gpu` previously folded the type check into
its length check and answered a non-bytes nonce with a complaint about
its length.

**Breaking for a v1 caller passing a string.** v1 has not shipped, and
the v0 clients keep the old signature untouched -- a 0.5.x program
migrating by class name alone is unaffected, and that surface is frozen
precisely so this kind of change cannot reach it.

The JavaScript check is at runtime rather than in the parameter type
alone: a plain-JS caller, or TypeScript holding an `any` out of
`JSON.parse`, reaches the method with a string and no compiler in the
way.

Both new tests were mutation-checked against the lenient behaviour they
replace.

…t some

Differential testing -- 194 identical JSON bodies through four real
clients, one fake agent per body -- put the four SDKs at 143 agreements
and 51 divergences. Every divergence was absence, `null`, or JSON type
confusion; none was bad hex, and none is reachable from a conforming
agent, which emits every field, always lowercase hex, never `null`. All
of them are reachable from a compromised or non-dstack server, which is
the threat model private keys, signature chain links and application
identity already take seriously.

Go was the outlier in 39 of them, and its failure mode was the worst
available: decoding into a `string` turned both an absent key and a JSON
null into "", "" hex-decodes to empty bytes, and the error was nil. An
error body arriving with a 200 -- the one shape the transport's status
check does not cover -- therefore returned a zero-length private key,
an empty app_id, and `err == nil`. Required fields now decode through a
pointer so absence is visible, `rpcError` surfaces the agent's own words,
and the fields whose absence is genuinely the empty default read the raw
JSON, because a pointer cannot tell an omission from a null and only one
of those is an answer.

JavaScript's bundle decoding kept the same gap the response fields had:
`vendor` and `format` came through a spread of the raw JSON, so a bundle
missing one yielded `undefined` from an interface declaring `string`.
Those two are what a caller switches on to pick a verifier, so the
evidence was not degraded, it was routed to no verifier at all --
quietly, since `undefined` matches no `case`.

Rust and Python needed nothing here; they already refused every one of
these bodies. The remaining seven divergences after the Go rewrite were
Go accepting `null` for `Info`'s plain string fields, fixed the same way.

The 194 bodies now agree 194/194.